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Abstract. NP-SPEC is a language for specifying problems in NP in a declarative 
way. Despite the fact that the semantics of the language was given by referring to 
Datalog with circumscription, which is very close to ASP, so far the only existing 
implementations are by means of ECL l PS e Prolog and via Boolean satisfia- 
bility solvers. In this paper, we present translations from NP-SPEC into various 
forms of ASP and analyze them. We also argue that it might be useful to incor- 
porate certain language constructs of NP-SPEC into mainstream ASP. 

1 Introduction 

NP-SPEC is a language that was proposed in 14121 in order to specify problems in the 
complexity class NP in a simple, clear, and declarative way. The language is based 
on Datalog with circumscription, in which some predicates are circumscribed, while 
others are not and are thus "left open". Some practical features are added to this basic 
language, often by means of reductions. 

The original software system supporting NP-SPEC was described in |2| and was 
written in the ECL l PS e Constraint Programming System, based on Prolog. A sec- 
ond software system, SPEC2SAlQ was proposed in J5J, which rewrites NP-SPEC into 
propositional formulas for testing satisfiability. The system has also been tested quite 
extensively in [5], also for several problems taken from CSPLIB, with promising re- 
sults. 

Interestingly, to our knowledge so far no attempt has been made to translate NP- 
SPEC into Answer Set Programming (ASP), which is very similar in spirit to Datalog 
with circumscription, and thus a good candidate as a transformation target. Moreover, 
several efficient ASP software systems are available, which should guarantee good per- 
formance. A crucial advantage of ASP versus propositional satisfiability is the fact that 
NP-SPEC problem descriptions are in general not propositional, and therefore a reduc- 
tion from NP-SPEC to SAT has to include an implicit instantiation (or grounding) step. 
Also ASP allows for variables, and ASP systems indeed provide optimized grounding 
procedures, which include many advanced techniques from database theory (such as 
indexing, join-ordering, etc). This takes the burden of instantiating in a smart way from 
the NP-SPEC translation when using ASP systems. 



* This work was supported by M.I.U.R. within the PRIN project LoDeN. 
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In this paper we provide a translation from NP-SPEC into various variants of ASP. 
We discuss properties and limitations of the translation and also provide a prototype im- 
plementation, for which we provide a preliminary experimental analysis, which shows 
that our approach is advantageous, in particular that it pays off if grounding tasks are 
delegated to existing systems. The rest of the paper is structured as follows: in sectionp] 
we review the language NP-SPEC and give a very brief account of ASP. In section [3] 
we provide the main ingredients for translations from NP-SPEC to ASP, and discuss 
properties and limitations. In section|4]we report on preliminary experimental results. 
Finally, in section|5]we draw our conclusions. 

2 Preliminaries: NP-SPEC and ASP 

We first provide a brief definition of NP-SPEC programs. For details, we refer to 0. 
We also note that a few minor details in the input language of SPEC2SAT (in which 
the publicly available examples are written) are different to what is described in [2 1. We 
will usually stick to the syntax of SPEC2SAT. 

An NP-SPEC program consists of two main sections^] one section called DATABASE 
and one called SPECIFICATION, each of which is preceded by the respective keyword. 

2.1 DATABASE 

The database section defines extensional predicates or relations and (interpreted) con- 
stants. Extensional predicates are defined by writing 

P = {ti, . . . ,t n }; 

where p is a predicate symbol and each ti is a tuple with matching arity. For unary 
predicates, each tuple is simply an integer or a constant symbol; for arity greater than 
1, it is a comma-separated sequence of integers or constant symbols enclosed in round 
brackets. Unary extensions that are ranges of integers can also be abbreviated to n..m, 
where n and m are integers or interpreted constants. Constant definitions are written as 

c = i; 

where i is an integer. 

Example 1. The following defines the predicate edge representing a graph with six 
nodes and nine edges, and a constant n representing the number of nodes. 

DATABASE 

n = 6; 

edge = {(1, 2), (3, 1), (2, 3), (6, 2), (5, 6), (4, 5), (3, 5), (1, 4), (4, 1)}; 



SPEC2SAT also has a third, apparently undocumented section called SEARCH, which seems to 
define only output features and which we will not describe here. 
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2.2 SPECIFICATION 

The SPECIFICATION section consists of two parts: a search space declaration and a 
stratified Datalog program. The search space declaration serves as a domain defini- 
tion for "guessed" predicates and must be one or more of the metafacts Subset (d, p), 
Permutation(d, p), Partitioned, p, n), and IntFunc(d, p, n..m), which we will de- 
scribe below. 

Subset (d, p). This is the basic construct to which all following search space dec- 
laration constructs are reduced in the semantic definition in J2). Here, d is a domain 
definition, which is either an extensional predicate, a range n..m, or a Cartesian product 
(><), union (+), intersection (*), or difference (— ) of two domains. Symbol p is a pred- 
icate identifier and the intended meaning is that the extension of p can be any subset of 
the domain definition's extension, thus giving rise to nondeterminism or a "guess". 

Example 2. Together with the code of Example [T] the following specification will rep- 
resent all subgraphs (including the original graph) as extensions of predicate subgraph. 

SPECIFICATION 

Subset(edge, subgraph). 

Permutation(d, p). Concerning this construct, d is again a domain definition, and p 
will have an extension in which each tuple of d is present and an additional argument 
associates a unique integer between 1 and the cardinality of the extension of d (say, c) 
to each tuple, thereby defining a permutation. The extensions of p thus define a bijective 
functions from tuples of the extension of d to {l..c}. 

Example 3. Together with the code of Example [T] the following specification will rep- 
resent all enumerations of edges. 

SPECIFICATION 

Permutation(edge, edgeorder). 

One extension of edgeorder that reflects the ordering of the edges as written in Exam- 
ple[T]is 

edgeorder(l, 2, 1), edgeorder(3, 1, 2), edgeorder(2, 3, 3), 
edgeorder(6, 2, 4), edgeorder(5, 6, 5), edgeorder(4, 5, 6), 
edgeorder(3, 5, 7), edgeorder(l, 4, 8), edgeorder(4, 1, 9). 

Partition(d, p, n). Also in this case p will have one argument more than d. In this 
case, extensions of p will define functions from tuples of the extension of d to {l..n}, 
thereby defining n (possibly empty) partitions. 

Example 4. Together with the code of Example [T] the following specification will rep- 
resent all possible pairs of graphs that partition the input graph. 



SPECIFICATION 

Partition(edge, partition, 2). 
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One extension of partition that has the first four edges in the first partition (i.e., 
partition 0) and the last five edges in the second partition (i.e., partition 1) would be 

partition(l, 2, 0), partition(3, 1, 0), partition(2, 3, 0), 
partition(6, 2, 0), partition(5, 6, 1), partition(4, 5, 1), 
partition(3, 5, 1), partition(l, 4, 1), partition(4, 1, 1). 

IntFunc(d, p, n..m). Again, p will have one argument more than d. Here, extensions 
of p will define functions from tuples of the extension of d to {n..m}. 

Example 5. The following specification is equivalent to the one in Example |4] 

SPECIFICATION 

IntFunc(edge, partition, 0..1). 

Stratified Datalog Program. The stratified Datalog program is written using < — 
as the rule implication symbol. It may contain built-in predicates (==, <, >, >=, <=, 
! =), arithmetic expressions, and stratified aggregates (COUNT, SUM, MIN, MAX). It may 
also contain integrity constraints, in which case rule heads contain the special symbol 

fail. Rule implication is denoted by < , the aggregates are written as for example 

SUM(p(*, _, Y), Z : n..m) where: * specifies the argument to be aggregated over; variables 
that are not shared with other rule literals are local (as a special case the anonymous 
variable _) and represent the arguments that are not fixed; variables that are shared with 
other rule literals are considered fixed in the aggregation; and variable Z will contain 
the valuation of the aggregate, which will must be in the range n..m. Comments may be 
written in C++ style (using / * */ or //). 

Example 6. As an example, consider the well-known Hamiltonian Cycle problem. The 
NP-SPEC distribution contains an example program for an example graph: 

DATABASE 

n = 6; / /no. of nodes 

edge = {(1,2), (3,1), (2,3), (6,2), (5,6), (4,5), (3,5), (1,4), (4,1)}; 
SPECIFICATION 

Perimitation({l..n}, path). 

fail < path(X, P), path(Y,P+l), NOT edge(X, Y). 

fail < path(X,n), path(Y, 1), NOT edge(X, Y). 

The DATABASE section contains an encoding of the example graph by means of the 
binary predicate edge and defines a constant n for representing the number of nodes 
of that graph. Implicitly it is assumed that the nodes are labeled by integers from 1 
to n. The SPECIFICATION section then first guesses a permutation of the nodes and 
then verifies the Hamiltonian Cycle condition by means of integrity constraints, one 
exploiting the linear order of the permutation identifiers, and another one to close the 
cycle from the last permutation identifier to the first one. 
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The semantics of NP-SPEC programs is provided by means of Datalog with Cir- 
cumscription, in which some predicates are minimized. That means that among all 
models only those which are minimal with respect to the minimized predicates are 
accepted. Moreover, among these only those which make the special symbol fail 
false are considered and referred to as answers. All metafacts are reduced to the ba- 
sic metafact Subset that effectively states that the predicate defined by the metafact is 
not minimized. For further details of the semantics, we refer to Q. 

Concerning ASP, we only give a very brief overview, details may be found in works 
such as 01113181 . An ASP program consists of rules 

U V • • • V L k : - Body 

where the Li are literals containing variables and constant^j(possibly containing strong 
negation) and Body, which is a conjunction of literals, that may also contain built-ins, 
aggregates and default negation. Rules without heads act like integrity constraints. The 
semantics is based on the Gelfond-Lifschitz reduct ifTTI and also guarantees minimality 
of the answer sets. 

Practical ASP systems differ in several details, for instance several do not support 
disjunction in rule heads, built-in predicates and arithmetic expressions may differ and 
also aggregates are sometimes written in slightly different ways. In this paper, we will 
use the syntax of gring o (|http : //potassco . sourcef orge . net/) and DLV 
( |http : / /www . dlvsy stem . com) . Both systems assume that the input programs 
are safe, that is, each variable in a rule must also occur in a positive body atom. While 
gringo can also parse disjunctive programs, clasp, the solver it is often used with, can 
only deal with nondisjunctive programs. 

Example 7. As an example, consider the Hamiltonian Cycle problem and instance from 
above. An ASP encoding similar to the NP-SPEC program seen earlier would be: 

^const n = 6 

edge(l, 2). edge(3, 1). edge(2, 3). edge(6, 2). edge(5, 6). 

edge(4, 5). edge(3, 5). edge(l, 4). edge(4, 1). 

d(l..n). 

path(X, l)Vpath(X, 2)Vpath(X, 3) Vpath(X, 4) Vpath(X, 5)Vpath(X, 6) : - d(X). 

: - path(X,A), path(Y,A). X ! = Y. 

: - path(X, P), path(Y, Z), not edge(X, Y), Z = P + 1. 

: -path(X,n), path(Y, 1), not edge(X,Y). 

This program is usable for gringo with clasp, using the — shift option (transforming 
the disjunctive rule into several nondisjunctive ones), and DLV. We can observe that the 
extensional definition is rewritten into a number of facts and that the constant definition 
also just changes syntax. As for the permutation statement, here we first use a predi- 
cate d representing the domain definition, and then a disjunctive rule and an integrity 
constraint. The disjunctive rule states that each tuple in the domain definition must be 
assigned one of the numbers 1 to 6, and the integrity constraint enforces the bijection, 



3 Many modern ASP systems also allow for function symbols, but they are not needed here. 
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that is, no different tuples of the domain definition must be assigned the same number. 
The final two integrity constraints are direct translations from the NP-SPEC program. 
The only difference is the arithmetic expression that has been moved outside the fact 
in order to conform to DLV's syntax (gringo would also have accepted the immediate 
translation from the NP-SPEC program). 



We now report how the various constructs of NP-SPEC programs can be translated 
into ASP. We start with the DATABASE section constructs. An extensional declaration 
of the form p = {ti, . . . , t n } will be translated to facts p(ti) • • • p(t n ), and one of the 
form p = {n..m} will be translated to facts p(n) • • • p(m). Constant declarations such as 
c = i, instead, will be managed in-memory. 

Now for the main task, translating the SPECIFICATION constructs. We first look at 
metafacts. The simplest one is Subset (d, p). The exact translation of this metafact (and 
all others as well) depends on how d is specified. First assume that it is an extensional 
predicate d of arity n, then we can directly use it and produce 



Otherwise, we will create an extensional predicate d of appropriate arity (assuming that 
it is a fresh symbol) as follows: 

- for the Cartesian product p >< q, the following set of facts is created: {d(x 1; . . . , 
x i+j) I p( x ij • ■ • , Xi) A q(x i+ i, . . . , x i+ j)}, where i and j are the arities of p and 
q, respectively; 

- for the union p + q, the following set of facts is created: {d(x 1; . . . , x ± ) | p(xi, . . . , 
Xi) V q(x 1; . . . , Xi)}, where i is the arity of both p and q; 

- for the intersection p * q, the following set of facts is created: {d(x l7 . . . ,Xi) | p(x 1; 
. . . , Xi) A q(x 1; . . . , Xi)}, where i is the arity of both p and q; and 

- for the difference p — q, the following set of facts is created: {d(xi, . . . , Xi) | p(xi, 

. . . , Xi) A ^.q(x 1; . . . , Xi)}, where i is the arity of both p and q, and ^.q(xi, . . . , Xi) 
is true if and only if the fact q(x 1; . . . , Xi) is not part of the translation. 

For nested domain definitions, we just repeat this process recursively using fresh sym- 
bols in each recursive step. In the following we will assume that domain definitions 
have been treated in this way and that the top-level predicate of the translation is d. If 
available (for instance when using gringo or lparse), we can also use choice rules for 
translating Subset(d, p): 



3 Translation from NP-SPEC to ASP 



p(X 



...,X n )V-p(X 1 ,...,X n ) : -d(X 1 ,...,X n ). 



For the metafact Permutation(d, p), we will create 

p(X 1; . . . , X n , 1) V . . . V p(X 1; . . . , X n , c) : - d(X 
:-p(X 1 ,...,X n ,A),p(Y 1 ,...,Y n ,A),X 1 !=Y 1 . 



...,x n ). 



-p(X 1 ,...,X n ,A),p(Y 1 ,...,Y n ,A),X n !=Y n . 
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where n is the arity of d and c is the cardinality of d. The first rule specifies intuitively 
that for each tuple in d one of p(X 1; . . . ,X n , 1) • • • p(X 1; . . . , X n , c) should hold, and by 
minimality exactly one of these will hold. The integrity constraints ensure that no dif- 
ferent numbers will be associated to the same tuple. As an alternative to the disjunctive 
rule, one can use a choice rule 

l{p(X 1 ,...,X n ,l..c)}l : -d(X l5 ...,X n ). 

Instead of the n integrity constraints it is possible to write just one using an aggregate, 
if available. In the DLV syntax, one could write 

: - #count{X 1 ,...,X n : p(X 1; . . . , X n , A)} > 1, p(_, A). 

or in gringo syntax 

: - 2 #count{p(Xl, . . . , X n , A)}, p(_, A). 

The remaining metafacts are actually much simpler to translate, as the bijection 
criterion does not have to be checked. For Partition(d, p, k), we will simply create 

p(Xi, . . . , X n , 0) V . . . V p(Xi, . . . , X n , k - 1) : - d(Xi, . . . , X n ). 

or the respective choice rule 

l{p(X 1 ,...,X n ,0..k- 1)}1 : -d(X 1 ,...,X n ). 

where n is the arity of d. For IntFunc(d, p, i.. j ), we will simply create 

p(X 1; . . . , X n , i) V . . . V p(X 1; . . . , X n , j) : - d(X l5 . . . , X n ). 

or the respective choice rule 

l{p(X 1 ,...,X n ,i..j)}l : -d(X 1; ...,X n ). 

where n is the arity of d. 

What remains are the Datalog rules of the SPECIFICATION section. Essentially, 

each Head < Body is directly translated into Head' : — Body', with only minor 

differences. If Head is fail, then Head' is empty, otherwise it will be exactly the same. 
The difference between Body and Body' is due to different syntax for arithmetics, aggre- 
gates and due to safety requirements. Concerning arithmetics, gringo can accept almost 
the same syntax as NP-SPEC with only minor differences (#abs instead of abs, #pow 
instead of ~), while DLV is much more restrictive. DLV currently does not support neg- 
ative integers and it does not provide constructs corresponding to abs and " . Moreover, 
arithmetic expressions may not be nested in DLV programs, but this limitation can be 
overcome by flattening the expressions. 

Concerning aggregates, DLV and gringo support similar syntax, which is a little bit 
different from the one used in NP-SPEC but rather straightforward to rewrite according 
to the following schema: Arguments marked with asterisks are first replaced with fresh 
variables; these are the arguments on which the aggregation function is applied. Apart 
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from COUNT, exactly one asterisk may appear in each aggregate. Hence, an aggregate 
SUM(p(*, _, Y), Z : n..m) is written in DLV's syntax as 

#sum{X:p(X,_,Y)} = Z, d(Z) 

and in gringo's syntax as 

Z #sum[p(X, _, Y) = X] Z, d(Z) 

where X is a fresh variable and d is a fresh predicate defined by facts d(n) • • • d(m). 
Aggregates MIN and MAX are rewritten similarly, while an aggregate 

C0UNT(p(*,_, *,Y),Z : n..m) 

is written in DLV's syntax as 

#count{X 1 ,X 2 : p(X 1 ,_,X 2 ,Y)} = Z, d(Z) 
and in gringo's syntax by 

Z#count{p(Xi,_,X 2 ,Y)} Z, d(Z). 

A more difficult problem presents the safety conditions enforced by the ASP sys- 
tems. NP-SPEC has a fairly lax safety criterion, while for instance DLV requires each 
variable to occur in a positive, non-builtin body literal, and also gringo has a similar cri- 
terion. This mismatch can be overcome by introducing appropriate domain predicates 
when needed. 

4 Experiments 

We have created a prototype implementation of the transformation described in sec- 
tion^ which is available at |http : //archives . alviano . com/npspec2asp/[ 
It is written in C++ using bison and flex, and called NPSPEC2ASP. The imple- 
mentation at the moment does only rudimentary correctness checks of the program and 
is focussed on generating ASP programs for correct NP-SPEC input. Moreover, at the 
moment it generates only the disjunctive rules described in section [3] rather than the 
choice rules, but we plan to add the possibility to create variants of the ASP code in the 
near future. For the experiments, the transformation used for Permutation produced 
the integrity constraint with the counting aggregate. 

We used this implementation to test the viability of our approach, in particular as- 
sessing the efficiency of the proposed rewriting in ASP with respect to the previously 
available transformation into SAT. In the benchmark we included several instances 
available on the NP-SPEC site. More specifically, we considered two sets of instances, 
namely the miscellanea and csplib2npspec benchmarks. Even if these instances have 
been conceived for demonstrating the expressivity of the language rather than for as- 
sessing the efficiency of an evaluator, it turned out that even for these comparatively 
small instances there are quite marked performance differences. Below we provide 
some more details on the testcases in the miscellanea benchmark. 
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- Coloring is an instance of the Graph Coloring problem, i.e., given a graph G and a 
set of k colors, checking whether it is possible to assign a color to each node of G 
in such a way that no adjacent nodes of G share the same color. The tested instance 
has 6 nodes and 3 colors. 

- In the Diophantine problem, three positive integers a, b, c are given, and an integer 
solution to the equation ax 2 + by = c is asked for. The parameters of the tested 
instance are a = 5, b = 3, and c = 710. 

- The Factoring problem consists of finding two non-trivial factors (i.e., greater than 
1) of a given integer n. In the tested instance, n — 10000. 

- In the Hamiltonian Cycle problem a graph G is given, and a cycle traversing each 
node exactly once is searched. The tested graph has 6 nodes. 

- An instance of the Job Shop Scheduling problem consists of integers n (jobs), m 
(tasks), p (processors), and D (global deadline). Jobs are ordered collections of 
tasks, and each task is performed on a processor for some time. Each processor 
can perform one task at a time, and the tasks belonging to the same job must be 
performed in order. The problem is checking whether it is possible for all jobs to 
meet deadline D. In the testcase, n = 6, m = 36, p — 6, and D = 55. 

- In the Protein Folding problem, a sequence of n elements in {H, P} is given, and 
the goal is to find a connected, non-overlapping shape of the sequence on a bi- 
dimensional, discrete grid, so that the number of "contacts", i.e., the number of 
non-sequential pairs of H for which the Euclidean distance of the positions is 1, is 
in a given range R. In the testcase, n = 6, and R = {1..12}. 

- In the Queens problem, an integer n is given, and the goal is to place n non- 
attacking queens on a n x n chessboard. In the tested instance, n = 5. 

- Given an array A of integers, the Sorting problem consists of arranging the elements 
of A in non-descending order. In the tested instance, the array has 7 elements. 

- An instance of the Subset Sum problem comprises a finite set A, a size s(a) £ N + 
for each a € A, and B € N + . The goal of the problem is checking whether there is 
a subset A' of A such that the sum of the sizes of the elements in A' is exactly B. 
In the tested instance, set A has 5 elements and B = 10. 

- In a Sudoku, the goal is to fill a given (partially filled) grid with the numbers 1 to 
9, so that every column, row, and 3x3 box indicated by slightly heavier lines has 
the numbers 1 to 9. 

- 3-SAT is a well-known NP-complete problem: Given a propositional formula T 
in conjunctive normal form, in which each clause has exactly three literals, is T 
satisfiable, i.e., does there exist an assignment of variables of T to {true, false} 
that makes T evaluate to truel The tested instance has 3 clauses. 

- The Tournament Scheduling problem consists of assigning the matches to rounds of 
a round-robin tournament for a sports league. The match is subject to several con- 
straints, such as: (i) complementary teams t\ and t% have complementary schedules, 
i.e., for each round 7-, if t\ plays home in r then t 2 plays away in r, and vice versa; 
(ii) two top matches cannot take place at distance smaller than a given value; (iii) 
any team cannot match two top teams at distance smaller than a given value. (See 
[5 1 for details.) The tested instance has 6 teams. 

Below we describe the testcases in the cspliblnpspec benchmark. 
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- Given neN, find a vector s = (s\, s n ) such that (i) s is a permutation of Z n = 
{0, 1, ... ,n — 1}; and (ii) the interval vector v = (|s 2 — Si | , \s 3 — s 2 \, ■ ■ ■ , \s n — 
s n -i\) is a permutation of Z n \{0} = {1,2, . . . ,n— 1}.A vector u satisfying these 
conditions is called an all-interval series of size n; the problem of finding such a 
series is the All-interval Series problem of size n. In the tested instance, n = 20. 

- In the BACP (balanced academic curriculum problem), each course has associated a 
number of credits and can have other courses as prerequisites. The goal is to assign a 
period to every course in a way that the number of courses and the amount of credits 
per period are in given ranges, and the prerequisite relationships are satisfied. The 
tested instance comprises 7 courses and 2 periods. 

- A BIBD is defined as an arrangement of v distinct objects into b blocks such that 
each block contains exactly k distinct objects, each object occurs in exactly r dif- 
ferent blocks, and every two distinct objects occur together in exactly A blocks. The 
parameters of the tested instance are v = 7, b = 7, k = 3, r = 3, and A = 1. 

- In the Car Sequencing problem, a number of cars are to be produced; they are not 
identical, because different options are available as variants on the basic model. 
The assembly line has different stations which install the various options (air- 
conditioning, sun-roof, etc.). These stations have been designed to handle at most 
a certain percentage of the cars passing along the assembly line. Consequently, the 
cars must be arranged in a sequence so that the capacity of each station is never ex- 
ceeded. In the testcase there are 10 cars, 6 variants on a basic model, and 5 options. 

- A Golomb ruler is a set of to integers — ai < a 2 < ■ ■ ■ < a m such that the 
m(m — l)/2 differences a,j — (1 < i < j < to) are distinct. In the tested 
instance, to = 8 and a m must be lesser than or equals to 10. 

- Langford's problem is to arrange k sets of numbers 1 to n so that each appearance 
of the number m is m numbers on from the last. In the tested instance, k = 3 and 
n = 9. 

- Given integers n and b, the objective of the Low Autocorrelation problem is to 
construct a binary sequence Si of length n, where each bit takes the value +1 or 
-1, so that E = J2tZl(C k ) 2 < b, where C k = J27=o^ Si ■ S l+k . In the tested 
instance, n = 5 and 6 = 2. 

- An order n magic square is a n x n matrix containing the numbers 1 to n 2 , with 
each row, column and main diagonal summing up to the same value. In our setting, 
n = 3. 

- The Ramsey problem is to color the edges of a complete graph with n nodes using 
at most k colors, in such a way that there is no monochromatic triangle in the graph. 
In the tested instance, n = 5 and k = 3. 

- The Round-robin Tournament problem is to schedule a tournament of n teams over 
n — 1 weeks, with each week divided into n/2 periods, and each period divided 
into two slots. A tournament must satisfy the following three constraints: every 
team plays once a week; every team plays at most twice in the same period over the 
tournament; every team plays every other team. In our setting, n = 4. 

- Schur's Lemma problem is to put n balls labelled {1, . . . , n} into 3 boxes so that 
for any triple of balls (x, y, z) with x + y = z, not all are in the same box. In the 
tested instance, n = 10. 
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- In the Social Golfer problem there are n golfers, each of whom play golf once a 
week, and always in groups of s. The goal is to determine a schedule of play for 
these golfers, to last I weeks, such that no golfer plays in the same group as any 
other golfer on more than one occasion. In our setting, n = 8, s = 2, and I = 4. 

The experiment has been executed on an Intel Core2 Duo P8600 2.4 GHz with 4 
GB of central memory, running Linux Mint Debian Edition (wheezy/sid) with kernel 
Linux 3.2.0-2-amd64. The tools SPEC2SAT and NPSPEC2ASP have been compiled 
with gcc 4.6.3. The other tools involved in the experiment are satz 215.2 [14|, minisat 
1.14 Q, gringo 3.0.4 OH, clasp 2.0.6 0, and DLV 2011-12-21 lfT2l . 

In our experiment, we first measured the running time required by SPEC2SAT and 
NPSPEC2ASP to rewrite the input specification into SAT and ASP, respectively. Then, 
for each SAT encoding produced by SPEC2SAT, we ran three SAT solvers, namely 
satz, minisat and clasp, to obtain one solution if one exists. For each of these executions 
we measured the time to obtain the solution or the assertion that none exists, thus the 
sum of the running times of SPEC2SAT and of the SAT solvers. Moreover, for each 
ASP encoding produced by NPSPEC2ASP, we ran two instantiators, namely gringo and 
DLV (with option --instantiate). For each of these runs we measured the time 
required to compute the ground ASP program, thus the sum of the running times of 
NPSPEC2ASP and of the instantiator. Finally, for each ground ASP program computed 
by gringo and DLV, we computed one solution by using clasp and DLV, respectively, 
and measured the overall time required by the tool-chain. We have also measured the 
sizes of the instantiated formulas and programs. For SPEC2SAT, we report the number 
of clauses in the produced formula and the number of propositional variables occurring 
in it. For DLV and gringo we report the number of ground rules produced and the 
number of ground atoms occurring in them. There is a slight difference in the statistics 
provided by DLV and gringo: DLV does not count ground atoms (and facts) that were 
already found to be true; to be more comparable, we added the number of facts for DLV. 

Experimental results concerning the miscellanea benchmark are reported in Table[T] 
We first observe that the time required by NPSPEC2ASP is below the measurement ac- 
curacy, while the execution time of SPEC2SAT is higher, sometimes by several orders 
of magnitude. In fact, SPEC2SAT has to compute a ground SAT instance to pass to a 
SAT solver, while NPSPEC2ASP outputs a non-ground ASP program. A fairer com- 
parison is obtained by adding to the time taken by NPSPEC2ASP the time required by 
the ASP instantiator to obtain a ground ASP program. Columns gringo and "DLV inst" 
report these times, which are however always less than those of SPEC2SAT. In Table|2] 
it can be seen that also the number of ground rules produced by the ASP systems is 
usually smaller than the number of clauses produced by SPEC2SAT, even if often the 
number of ground atoms exceeds the number of propositional variables. 

Concerning the computation of one solution from each ground specification, all 
considered SAT and ASP solvers are fast in almost all tests. The only exceptions are satz 
for proteinFolding, which exceeds the allotted time, and DLV for jobShopScheduling, 
whose execution lasted around 88 seconds. We also note that DLV has not been tested 
on 2 instances containing negative integers, which are not allowed in the DLV language. 

Table [3] reports experimental results concerning the csplib2npspec benchmark. We 
start by observing that instances in this benchmark are more resource demanding than 
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instances in the miscellanea benchmark. In fact, we note that golombRuler is too diffi- 
cult for SPEC2SAT, which did not terminate on the allotted time on this instance. On the 
other hand, the rewriting provided by NPSPEC2ASP is processed in around 28 seconds 
by gringo+clasp and in around 24 seconds by DLV. Another hard instance is alllnterval, 
for which only satz and DLV terminated in the allotted time. All other solvers, includ- 



Table 1. Running times on the miscellanea benchmark 



Instance 


SPEC2SAT 


NPSPEC2ASP 


only 


satz minisat 


clasp 


only 


DLV 
inst 


DLV gringo gri " g ° 
a +clasp 


coloring 





01 


0.01 





06 





01 





00 


0.00 


0.00 





00 





01 


diophantine 





75 


0.81 





77 





79 





00 


0.05 


0.04 





04 





06 


factoring 


5 


99 


10.21 


6 


09 


7 


15 





00 


0.23 


0.38 





17 


1 


05 


hamiltonianCycle 





03 


0.03 





03 





03 





00 


0.01 


0.01 





01 





01 


jobShopScheduling 


43 


39 


44.89 


44 


64 


44 


34 





00 


1.63 


87.96 


1 


01 


1 


92 


proteinFolding 


132 


17 


>600 


165 


03 


134 


49 





00 


N/A* 


N/A* 


2 


51 


4 


18 


queens 





03 


0.04 





03 





04 





00 


0.01 


0.01 





01 





01 


sorting 





03 


0.03 





03 





03 





00 


0.01 


0.01 





01 





01 


subsetSum 





11 


0.11 





10 





11 





00 


0.00 


0.00 





00 





01 


sudoku 


3 


05 


3.07 


3 


06 


3 


04 





00 


0.11 


0.11 





11 





17 


threeS at 





01 


0.01 





01 





01 





00 


N/A* 


N/A* 





01 





01 


tournaments cheduling 





45 


0.45 





45 





45 





00 


0.04 


0.03 





02 





02 



* The instance contains negative integers. 



Table 2. Instance sizes of the miscellanea benchmark 



Instance 


SPEC2SAT 


NPSPEC2ASP 


DLV 


grinj 


;o 


Clauses Variables 


Rules Atoms 


Rules Atoms 


coloring 


45 


18 


40 


31 


58 


38 


diophantine 


14,628 


140 


9,800 


142 


9,940 


145 


factoring 


123,748 


498 


61,998 


500 


62,496 


503 


hamiltonianCycle 


348 


36 


261 


99 


291 


94 


jobShopScheduling 


209,495 


1,980 


156,107 


2,052 


158,087 


2,089 


proteinFolding 


735,721 


669 


N/A* 


N/A* 


520,107 


347 


queens 


165 


25 


125 


65 


145 


61 


sorting 


427 


49 


252 


126 


294 


120 


subsetSum 


1,418 


125 


49 


54 


100 


77 


sudoku 


33,825 


1,458 


24,777 


2,545 


25,263 


1,736 


threeSat 


30 


39 


N/A* 


N/A* 


87 


76 


tournamentScheduling 


1,641 


108 


1,675 


115 


1,810 


182 



* The instance contains negative integers. 
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ing gringo+clasp, exceeded the allotted time, even if the NPSPEC2ASP rewriting and 
the instantiation by gringo is produced in less time than the output of SPEC2SAT. This 
instance is an outlier in our experiments. In almost all other instances the ASP solvers 
compute solutions in less than 1 second, while SAT solvers typically require several 
seconds, see in particular langford, magicSquare and low Autocorrelation. The size of 
the programs produced by the ASP instantiators is always smaller than the size of the 
formulas produced by SPEC2SAT, sometimes by orders of magnitude, even if the num- 
ber of ground atoms often exceeds the number of propositional variables. A major cause 
for the difference in size appear to be aggregates in the problem specification, which are 
supported natively by ASP systems, but require expensive rewritings for SAT solvers. 

The experimental results show that translating NP-SPEC programs into ASP rather 
than SAT seems to be preferable, due to the fact that sophisticated instantiation tech- 
niques can be leveraged. Moreover, also the nondeterministic search components of 
ASP systems can compete well with SAT solvers, making the use of ASP solvers very 
attractive for practical purposes. 

5 Conclusion 

In this paper we have presented a transformation of NP-SPEC programs into ASP. The 
translation is modular and not complex at all, allowing for very efficient transforma- 
tions. Compared to the previously available transformation into Boolean satisfiability, 
there are a number of crucial differences: While our transformation is from a formalism 
with variables into another formalism with variables, Boolean satisfiability of course 
does not allow for object variables. Therefore any transformation to that language has 



Table 3. Running times on the csplib2npspec benchmark 



Instance 


SPEC2SAT 


NPSPEC2ASP 


only 


satz minisat clasp 


only 


DLV 
inst 


DLV 


gringo 


gringo 
+ clasp 


alllnterval 


1.43 


36.98 


>600 


>600 


0.00 


0.07 


0.88 


0.06 


>600 


bacp 


6.15 


6.33 


6.18 


6.22 


0.00 


0.01 


0.01 


0.01 


0.01 


bibd 


3.98 


4.20 


4.03 


4.06 


0.00 


0.03 


0.11 


0.03 


0.03 


carSequencing 


8.69 


14.26 


8.82 


8.86 


0.00 


0.87 


0.83 


0.34 


0.48 


golombRuler 


>600 


>600 


>600 


>600 


0.00 


23.20 


23.70 


26.93 


28.19 


langford 


11.57 


12.58 


12.28 


12.62 


0.00 


0.04 


0.90 


0.03 


0.09 


low Autocorrelation 


23.17 


24.02 


23.15 


23.36 


0.00 


N/A* 


N/A* 


0.03 


0.03 


magicSquare 


10.55 


10.74 


10.59 


10.54 


0.00 


0.17 


21.94 


0.12 


0.32 


ramseyProblem 


0.02 


0.02 


0.02 


0.02 


0.00 


0.00 


0.00 


0.01 


0.01 


roundrobinTournament 


2.11 


2.27 


2.15 


2.14 


0.00 


0.02 


0.02 


0.01 


0.02 


schursLemma 


0.13 


0.14 


0.14 


0.14 


0.00 


0.01 


0.01 


0.01 


0.01 


socialGolfer 


7.32 


7.45 


7.52 


7.52 


0.00 


0.09 


0.14 


0.05 


0.07 



* The instance contains negative integers. 
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to do an implicit instantiation. It is obvious that instantiation can be very costly, and thus 
using sophisticated instantiation methods is often crucial. However, optimization meth- 
ods for instantiation are often quite involved and not easy to implement, and therefore 
adopting them in a transformation is detrimental. After all, the appeal of transforma- 
tions are usually their simplicity and the possibility to re-use existing software after 
the transformation. Our transformation method does just that; by not instantiating it is 
possible to re-use existing instantiators inside ASP systems, many of which use quite so- 
phisticated techniques like join ordering heuristics, dynamic indexing and many more. 
We have provided a prototype implementation that showcases this advantage. Even if 
only rather small examples were tested, already in most of those cases a considerable 
advantage of our method can be observed. 

There is a second aspect of our work, which regards ASP. As can be seen in sec- 
tion^ the translation of Permutation either gives rise to possibly many integrity con- 
straints or one with an aggregate. In any case, all current ASP instantiators will material- 
ize all associations between tuples of the domain definition and the permutation identi- 
fiers, even if the identifiers are not really important for solving the problem. This means 
that there are obvious symmetries in the instantiated program. There exist proposals 
for symmetry breaking in ASP (e.g. [6|), but they typically employ automorphism de- 
tection. We argue that in cases like this, a statement like Permutation, Partition, 
or IntFunc would make sense as a language addition for ASP solvers, which could 
exploit the fact that the permutation identifiers introduce a particular known symmetry 
pattern that does not have to be detected by any external tool. 



Table 4. Instance sizes of the csplib2npspec benchmark 



Instance 


SPEC2SAT 


NPSPEC2ASP 


DLV 


gringo 


Clauses Variables 


Rules Atoms 


Rules Atoms 


alllnterval 


21,737 


761 


9,239 


1,639 


9,961 


1,601 


bacp 


39,531 


1,518 


314 


316 


436 


360 


bibd 


31,843 


4,424 


2,684 


2,047 


4,091 


2,279 


carSequencing 


39,875 


786 


33,398 


219 


33,506 


218 


golombRuler 


N/A** 


N/A** 


653,593 


96 


1,149,561 


105 


langford 


130,518 


7299 


3,736 


793 


4,015 


803 


low Autocorrelation 


186,407 


5,952 


N/A* 


N/A* 


2,339 


1,041 


magic Square 


38,564 


1,975 


5458 


872 


18,445 14,513 


ramseyProblem 


80 


30 


60 


50 


90 


61 


roundrobinTournament 


9,272 


456 


1,203 


275 


1,467 


400 


schursLemma 


175 


30 


155 


40 


185 


51 


socialGolfer 


21,600 


1,424 


11,097 


441 


11,321 


442 



* The instance contains negative integers. 
** The system did not terminate in 30 minutes. 
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Future work consists of consolidating the prototype software and extending the ex- 
perimentation. Moreover, we intend to investigate the possibility to extend our trans- 
formation to work with other languages that are similar to NP-SPEC. Finally, we also 
intend to explore the possibility and impact of introducing Permutation, Partition, 
or IntFunc into ASP languages. 
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